home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93c.txt / 000006_icon-group-sender _Sun Jul 11 12:47:22 1993.msg < prev    next >
Internet Message Format  |  1994-02-02  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 11 Jul 1993 10:14:14 MST
  2. Date: Sun, 11 Jul 93 12:47:22 EDT
  3. From: Paul_Abrahams@MTS.cc.Wayne.edu
  4. To: icon-group@cs.arizona.edu
  5. Message-Id: <699110@MTS.cc.Wayne.edu>
  6. Subject: Sort enhancements for records and lists
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. I'd like to revisit a question that I know has come up before: enhancing
  11. the sort function to provide a useful treatment of records and lists.
  12.  
  13. First, a general observation: the current definition of record sorting is
  14. that records are sorted in order of their creation times.  Lists are
  15. treated similarly.  It's hard to imagine how that ordering can be put to
  16. a useful purpose.  Therefore it's reasonable to treat the ordering of
  17. records and lists during sorting as being undefined and thus available
  18. for redefinition.  Defining an order (however that is done) is very
  19. unlikely to invalidate any existing programs.
  20.  
  21. The obvious rule for sorting lists is that they are sorted by their first
  22. element; within equal first elements, by their second element, and so
  23. forth.  This simple extension would provide multi-field sorting,
  24. something that many people have requested.
  25.  
  26. Records can be sorted by the same rule, treating records (regardless of
  27. their types) as lists of their components.  Since there is no obvious
  28. ordering among different record types, this treatment is as good as any;
  29. sorting collections of records of diverse types is not particularly
  30. useful.
  31.  
  32. Since &null already comes first in sort order, missing elements always
  33. sort ahead of elements that were given explicitly without any special
  34. provisions (for both records and lists).
  35.  
  36. It's worth noting that this multi-field sort does have its limitations.
  37. In particular, it doesn't provide for sorting some fields in increasing
  38. order and others in decreasing order.  (If all fields are in decreasing
  39. order, the desired result can be gotten by reversing the list produced by
  40. sorting in increasing order.)  This deficiency could be gotten round by
  41. providing a fourth argument, a list of "+"s and "-"s, that specifies the
  42. direction of sorting consecutive fields.
  43.  
  44. All this is modulo the standard observation that the Icon Project has
  45. limited resources and implements only those enhancements that it
  46. considers worth the expenditure of those resources.
  47.  
  48. Paul Abrahams
  49. Reply-To: abrahams@acm.org
  50.